Back to Contents Previous Next
12. Loading files into memory
There are many circumstances where you will wish/need to load an existing file into memory. In particular, the display and/or printing of drawfiles, sprites, JPEGs generally requires them to be loaded into the computer memory first.
Dr Wimp provides a standard method for loading any file into memory. It is a simple three-step procedure, but it must be followed rigourously. The steps are:
1) measure size of file using FNwimp_measurefile
;
2) create memory block of at least this size;
3) load file into block with the appropriate file-loading wimp-function.
and there are currently four choices for Step 3):
FNwimp_loadsprites()
- for sprite-files
FNwimp_loaddfile()
- for drawfiles
FNwimp_loadjpegfile()
- for JPEG files
FNwimp_loadfile()
- for any other types of file
A typical coding sequence for a single file - taking a sprite-file as an example - is:
size%=FNwimp_measurefile(spritefile$,0)
DIM block% size%:REM** Or create a Dynamic Area instead. **
dummy%=FNwimp_loadsprites(spritefile$,block%,0)
Step 1), the use of FNwimp_measurefile()
, is very important and you should not measure the file size in any other way. The first parameter is the full path of the file to be loaded. The second parameter is a flag determining whether the wimp-function will give a warning if the file cannot be found. Here it is set to 0, meaning that no warning will be given. Setting it to 1 will give a warning.
Step 2), creating the block of memory, is straightforward and using a Dynamic Area (see Section 2.20) is probably better than DIM
- but either is fine.
Step 3), the actual loading of the file into the created memory block, needs more explanation and although our example uses FNwimp_loadsprites()
exactly the same comments apply to the other available file-loading wimp-functions. The first parameter is, as before, the full path of the file to be loaded. The second parameter is the start address of the memory block into which the file is to be loaded - here block%
. The third parameter, again as before, is a flag determining whether the wimp-function will give a warning if the file cannot be found.
The critical point to note is that this file-loading wimp-function is an FN and hence returns a value - assigned to dummy%
here. The returned value is the address of the next byte in the memory block after the file has been loaded. This may seem a little odd at the moment but comes into its own when we want to load more than one file into a single memory block - see next. In the above example we are only concerned with one file so the returned value is of no interest to us - hence the assignment to the variable dummy%
(which needs to be unused elsewhere and best made LOCAL
!).
With the sprite-file safely loaded into memory, the start address block%
effectively becomes the handle of the loaded sprite-file for display/printing/saving etc. - and this is covered in later Sections.
If more than one file is to be loaded then, of course, there is nothing wrong with using the above procedure more than once. However, it is just as easy to measure all the files first and create one block large enough to load them all. The coding then becomes:
size%=0
size%+=FNwimp_measurefile(file1$,0)
size%+=FNwimp_measurefile(file2$,0)
size%+=FNwimp_measurefile(file3$,0)
DIM block% size%:REM** Or create a Dynamic Area instead. **
first%=block%
second%=FNwimp_loadsprites(file1$,first%,0)
third%=FNwimp_loadsprites(file2$,second%,0)
dummy%=FNwimp_loadsprites(file3$,third%,0)
The result is that the three files are loaded into one block and their respective handles become first%
, second%
and third%
- and this method can be extended as necessary, with the final return always being assigned to an arbitrary unused variable.
(There is, of course, no reason why all the files have to be of the same type. If they are different then just ensure that the appropriate file-loading wimp-functions are put in their corresponding places in the last three lines.)
It is very important that you become familiar with this file-loading sequence as it will be assumed in several of the following Sections.
When using the non-file-specific wimp-function FNwimp_loadfile()
, the loading of a file automatically stores the length of the file in the 4-byte word preceding the returned handle. If the contents of the loaded file are amended in any way whilst it is in memory it is vital that the file-size is changed accordingly - otherwise its counterpart PROCwimp_savefile()
- see next Section - will not work properly.
It is worth remembering here that a spritefile can hold one or more sprites. A spritefile (file-type &FF9/’Sprite’) has, like any other file, a name and, independently, each sprite within it has a separate name.
You can see which sprites are held within any spritefile by double-clicking on it - which causes !Paint to be loaded and the sprites are then seen in a filer-like window. (If the sprite-file holds only one sprite than !Paint will also open a Paint window with that sprite shown - ready for editing etc.)
Top of page Back to Contents Previous Next